Check if this issue is valid — if so, understand the root cause and fix it. At lib/onboarding/runColdStartNudgeSweep.ts, line 76:

<comment>Overlapping sweep invocations can send this nudge twice: both pass the read-before-send check before either inserts its marker. Reserve a per-account nudge marker atomically before calling Resend (with a DB uniqueness constraint/claim), then send only for the invocation that acquired it.</comment>

<file context>
@@ -0,0 +1,84 @@
+  for (const accountId of coldStart) {
+    // Sequential on purpose: a nudge sweep has no latency requirement, and this
+    // keeps the send rate gentle.
+    if (await sendColdStartNudgeEmail({ accountId })) sent += 1;
+  }
+
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At lib/onboarding/runColdStartNudgeSweep.ts, line 60:

<comment>A transient `email_send_log` read failure turns this dedupe set empty and sends a nudge to accounts already nudged. Treat failure to load prior markers as a failed/no-op sweep rather than as no markers.</comment>

<file context>
@@ -0,0 +1,84 @@
+    selectRosteredAccountIds(welcomedAccountIds),
+    selectEmailSendLog({
+      status: "sent",
+      rawBodyLike: `"type":"${COLD_START_NUDGE_EMAIL_LOG_TYPE}"`,
+    }),
+  ]);
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At lib/emails/sendColdStartNudgeEmail.ts, line 48:

<comment>A successful delivery can be nudged again after an `email_send_log` write failure, because `logEmailAttempt` swallows that failure while the sweep's only idempotency record is this `sent` row. Consider durable claim/idempotency handling before sending so retries cannot issue another Resend request when recording the first send fails.</comment>

<file context>
@@ -0,0 +1,59 @@
+      return false;
+    }
+
+    await logEmailAttempt({
+      rawBody,
+      status: "sent",
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At lib/onboarding/coldStartNudgeHandler.ts, line 32:

<comment>The error response leaks `error.message` into the HTTP response body when the caught error is an `Error` instance. Both existing cron handlers (`getCreditSpendDigestHandler` and `playcountMaintenanceHandler`) always return a hardcoded string ("Internal server error" / "Internal error") and never include the raw exception text in the response. Leaking error messages can expose stack traces, DB column names, file paths, or other internal details. Log the full error server-side (already done), but return a hardcoded message to the caller.</comment>

<file context>
@@ -0,0 +1,37 @@
+    return NextResponse.json(
+      {
+        status: "error",
+        error: error instanceof Error ? error.message : "Internal server error",
+      },
+      { status: 500, headers: getCorsHeaders() },
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At lib/emails/renderEmailLayout.ts, line 17:

<comment>The comments in `renderEmailLayout.ts` reference `DESIGN.md §3` and `DESIGN.md four-font system`, but `DESIGN.md` does not exist in the repository. Citing a non-existent document misleads future maintainers and is an example of a fabricated reference that Rule 4 specifically flags. Remove the `DESIGN.md` citations or create the file with the cited sections.</comment>

<file context>
@@ -0,0 +1,88 @@
+  cta?: EmailLayoutCta;
+};
+
+// Brand tokens (DESIGN.md §3) — kept literal because email clients can't read
+// CSS custom properties. Achromatic chrome; color comes from content.
+const INK = "#0a0a0a"; // --foreground
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At lib/emails/sendScheduleConfirmationEmail.ts, line 40:

<comment>Concurrent retries can send duplicate schedule confirmations: this check and the later log write do not reserve the task before the Resend call. Use an atomic, uniquely constrained send reservation/idempotency key before sending, then update it with the result.</comment>

<file context>
@@ -0,0 +1,90 @@
+}): Promise<void> {
+  try {
+    const marker = `"task_id":"${taskId}"`;
+    const alreadySent = await selectEmailSendLog({
+      accountId,
+      status: "sent",
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At lib/tasks/createTaskHandler.ts, line 35:

<comment>Task creation now waits for several email/DB network calls before returning success. A slow or stalled email dependency can make an already-created schedule appear failed to the client and encourage duplicate task retries; enqueue the confirmation outside this request lifecycle (or otherwise bound it) instead of awaiting delivery here.</comment>

<file context>
@@ -28,6 +29,17 @@ export async function createTaskHandler(request: NextRequest): Promise<NextRespo
+    // Bridge from signing up to the first report landing (chat#1889): confirm
+    // what was scheduled and when. Fires after the schedule is materialized,
+    // and is best-effort inside, so it can never fail task creation.
+    await sendScheduleConfirmationEmail({
+      accountId: validatedBody.account_id,
+      taskId: createdTask.id,
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At lib/emails/describeCronCadence.ts, line 48:

<comment>Sunday schedules written with the valid `7` cron value render as raw cron text instead of a Sunday cadence. Treat `7` as the same Sunday index as `0` so confirmations remain human-readable for both supported forms.</comment>

<file context>
@@ -0,0 +1,53 @@
+
+  if (dayOfWeek === "*") return `every day at ${at}`;
+
+  if (/^[0-6]$/.test(dayOfWeek)) {
+    return `${WEEKDAYS[Number(dayOfWeek)]} at ${at}`;
+  }
</file context>